Inhalt: Hier wird die zu einem ISO-Compiler gehrende Bibliothek beschrieben.
        Dabei wird auch auf die Eigenschaften der vorliegenden Implementierung
        eingegangen.
        Unbedingt vor Benutzung der ISO-Module lesen!


Die zu einem ISO-Compiler gehrende Bibliothek teilt sich in drei groe
Bereiche auf:

1) Die Systemmodule:

   -- SYSTEM, EXCEPTIONS, M2EXCEPTION, TERMINATION, COROUTINES

   Das sind Module, die -- so wie 'SYSTEM' -- nicht oder nur schwer mit
   M2-Mitteln implementierbar sind. Sie werden vorzugsweise direkt
   in den Compiler eingebaut. Diese Module mssen auf jeden Fall
   vorhanden sein.

2) Die separaten (im Gegensatz zu den internen Systemmodulen) Module
   der Standardbibliothek:

   -- LowReal, LowLong, CharClass, Storage

   Diese Module knnen mit M2-Mitteln realisiert werden und mssen
   ebenfalls vorhanden sein. Sie sind jedoch stark systemspezifisch.

3) Die Standardbibliothek

   Mit diesen Modulen hat die/der Programmierer(in) am hufigsten zu tun.
   Es mssen nicht alle Module existieren. Die Standardbibliothek
   teilt sich wiederum in mehrere Bereiche auf:

   o Systemuhr
     -- SysClock

   o Stringbearbeitung
     -- Strings

   o Konvertierung zwischen externer Darstellung (Strings) und interner
     Darstellung (Zahlen)
     -- ConvTypes, WholeConv, RealConv, LongConv, WholeStr, RealStr, LongStr

   o Mathematik
     -- RealMath, LongMath, ComplexMath, LongComplexMath

   o Prozesse
     -- Processes, Semaphores

   o Ein-, Ausgabe
     (Universeller Teil)
     -- IOConsts, IOChan,
     -- IOResult, RawIO, TextIO, WholeIO, RealIO, LongIO,
     -- SIOResult, SRawIO, STextIO, SWholeIO, SRealIO, SLongIO,
     (Gerteabhngiger Teil)
     -- ChanConsts, IOLink,
     -- ProgramArgs, StdChans, TermFile, RndFile, SeqFile, StreamFile


Die Systemmodule und separaten Module der Standardbibliothek mssen
bei einem ISO-Compiler mitgeliefert werden und die dort enthaltenen
Objekte mssen in Syntax und Semantik (soweit diese nicht implementierungs-
abhngig ist) der ISO-Beschreibung entsprechen (die informelle
Beschreibung ist als Kommentar in den Definitionsmodulen enthalten).
Einzig das Modul SYSTEM darf erweitert werden (nicht jedoch reduziert).
Die Module der Standardbibliothek mssen nicht alle mitgeliefert werden;
wenn jedoch ein Modul den Namen eines der ISO-Module hat, mssen die dort
enthaltenen Objekte, wie oben, in Syntax und Semantik der ISO-Beschreibung
entsprechen. Ein Erweitern oder Reduzieren der Module ist nicht erlaubt.

Fr die Zahlenverarbeitung gilt: Da REAL und LONGREAL verschiedene Typen
sind, gibt es jedes Modul, das sich mit reellen Zahlen beschftigt,
sowohl in einer Ausfhrung fr REAL-Zahlen als auch fr LONGREAL-Zahlen,
wobei aber ansonsten beide Module sowohl in den Bezeichnungen als auch
in der Funktion identisch sind. Fr die Verarbeitung ganzer Zahlen
gibt es jeweils nur ein Modul, das sowohl Prozeduren fr CARDINAL als
auch fr INTEGER enthlt, wobei dies die jeweils grten ganzzahligen Typen
sind. Die Prozeduren unterscheiden sich nur leicht in der Namensgebung
(*Card* oder *Int*), bieten aber sonst die gleiche Funktionalitt.

Implementierung: Da nicht bei allen Compilern INTEGER und CARDINAL die
grten vorhandenen Ganzzahltypen sind, werden stattdessen die Typen
SIGNED und UNSIGNED aus 'PORTAB' verwendet.

Es folgt eine kurze Beschreibung der Module der Standardbibliothek,
wobei auch auf die speziellen Eigenschaften der Implementierung
eingegangen wird; eine weitergehende Beschreibung ist in den Modulen
selbst enthalten.


Die Systemmodule:
=================

SYSTEM
------
Das bliche, allerdings mit ein paar nderungen und Erweiterungen: Der
kleinste universelle Datentyp ist nicht mehr BYTE oder WORD, sondern LOC;
ein ARRAY OF LOC als Prozedurparameter akzeptiert also beliebige Parameter.
BYTE und WORD kann es aber weiterhin geben. Zustzlich gibt es noch
Funktionen, um mit Adressen rechnen zu knnen, da ADDRESS und
CARDINAL/LONGCARD nicht mehr kompatibel sind, und Funktionen fr das
bitweise Verschieben und Rotieren von Bitmengen.

Implementierung:
Mehr oder weniger vollstndig durch den jeweiligen Compiler implementiert.


EXCEPTIONS
----------
Hiermit lassen sich benutzerdefinierte Ausnahmen auslsen (RAISE), im
Gegensatz zu den automatisch vom Laufzeitsystem erzeugten. Weiterhin lassen
sich Exceptionnummer und -text sowie der augenblickliche Ausfhrungszustand
des Programms (in Ausnahmebehandlung oder nicht) erfragen.

Implementierung:
Natrlich lassen sich ohne Untersttzung durch den Compiler keine Ausnahmen
implementieren, da sie direkt bei der Codeerzeugung bercksichtigt werden
mssen. Allerdings fhrt das Auslsen einer Ausnahme nach ISO zur Beendigung
des Programms, wenn es keinen Handler fr diese Ausnahme gibt. Genau so ist
dann auch RAISE implementiert: Bei Aufruf dieser Prozedur wird das
Programm terminiert, wobei u.U. noch die mit "atexit()" (aus dem POSIX-Modul
'DosSystem') installierten Terminierungsroutinen ausgefhrt werden. Das ist
zwar nur ein schwacher Abklatsch der mit Ausnahmen und Handlern erreichbaren
Mglichkeiten, mir ist aber nichts Besseres eingefallen.


M2EXCEPTION
-----------
Definiert die Ausnahmen, die vom Modula-Laufzeitsystem ausgelst werden
knnen, und Abfragefunktionen, mit denen sich feststellen lt, ob, und wenn
ja, welche Laufzeitausnahme ausgelst wurde.

Implementierung:
NICHT IMPLEMENTIERT


TERMINATION
-----------
Abfragefunktionen, um festzustellen, ob mit der Terminierung begonnen oder
HALT aufgerufen wurde.

Implementierung:
NICHT IMPLEMENTIERT


COROUTINES
----------
Die blichen Prozeduren fr Koroutinen, allerdings ist die Schnittstelle
von Koroutinen zu Interrupts wesentlich mehr ausgearbeitet. In diesem
Zusammenhang gibt es auch einen neuen Standarddatentyp PROTECTION mit den
zwei vordefinierten Konstanten INTERRUPTABLE und UNINTERRUPTABLE, der
den einfachen Zahlenwert der frheren Modulprioritt ersetzt.

Implementierung:
NICHT IMPLEMENTIERT


Die separaten (System)Module:
=============================

LowReal, LowLong
----------------
Diese Module stellen Informationen ber den internen Aufbau der verwendeten
Real-Darstellung zur Verfgung. Mit den vorhandenen Konstanten und Prozeduren
lassen sich hhere Funktionen, wie z.B. die mathematischen Module der
Standardbibliothek, implementieren. Auerdem lassen sich, falls mglich,
die Eigenschaften der Real-Darstellung verndern.

Implementierung:
Die bool'schen Konstanten, die etwas ber die Erfllung bestimmter Standards
oder exakte Rundung aussagen, sind sicherheitshalber alle auf FALSE
gesetzt, da ich nicht genug Informationen ber die in den Laufzeitsystemen
verwendeten Routinen habe, um deren Eigenschaften 100%-ig bestimmen zu knnen.

Megamax (MM2) verwendet ein eigenes Real-Format, whrend die anderen
Systeme die IEEE-Darstellung verwenden. Allen per Software realisierten
Prozeduren ist gemeinsam, da keine denormalisierten Zahlen untersttzt
werden, d.h ein Wert der kleiner als der kleinste normalisierte Wert ist,
wird als Null behandelt. Ist eine per Line-F direkt ansprechbare FPU im
Rechner (nicht 68040), wird sie, auer bei Megamax, von einigen Prozeduren
auch verwendet (siehe auch FPU.TXT), wobei dann auch denormalisierte Zahlen
erzeugt werden knnen. "setMode()" und "currentMode()" haben nur dann eine
Funktion, wenn eine FPU vorhanden ist; in diesem Fall wird mit den Prozeduren
das Kontrollregister FPCR bearbeitet. Wenn keine FPU vorhanden ist, wird
bei "currentMode()" eine Konstante zurckgeliefert. Ausnahmen werden von den
per Software realisierten Prozeduren nicht erzeugt. Wenn mit "setMode()"
jedoch die Ausnahmen der FPU aktiviert werden, knnen Softwareinterrupts
erzeugt werden, fr die dann auch ein Traphandler vorhanden sein mu;
dieser wird jedoch nicht von M2LIB zur Verfgung gestellt. Defaultmig
sind alle Ausnahmen der FPU deaktiviert.

MM2:
o (LowReal) Eine Zahl wird als Null betrachtet, wenn Bit 31 nicht gesetzt ist.
LPRM2, SPCM2, TDIM2, HM2 (nur Software):
o Eine Zahl wird als Null betrachtet, wenn der Exponent Null ist.
o Negative Null und NaN werden nicht untersttzt.
o Von einigen Funktionen kann +/-Inf erzeugt werden.

Die Anwendung des Moduls 'LowReal' wird im Testmodul 'TLowReal' demonstriert.
Die Anwendung des Moduls 'LowLong' wird im Testmodul 'TLowLong' demonstriert.


CharClass
---------
Mit den hier enthaltenen Prozeduren knnen Ausdrcke des Typs CHAR
klassifiziert werden (Ist-Buchstabe, Ist-Zahl usw.). Wichtig ist, da es
sich um eine implementierungsspezifische Klassifizierung handelt, d.h.
welche Zeichen zu welcher Klasse gehren ist nicht festgelegt und kann
von Implementierung zu Implementierung differieren!

Implementierung:
Die Prozeduren sind mit Hilfe der in ``C'' blichen Klassifizierungsfunktionen
(isalpha, isdigit usw.) aus dem POSIX-Modul 'ctype' implementiert, die ber
das Locale LC_CTYPE beeinflut werden knnen. Ohne weitere Einstellungen
ist das POSIX-Locale aktiv, d.h. es werden die im amerikanischen blichen
Zuordnungen verwendet. Eine Beeinflussung des Locales ist ber die Funktionen
des POSIX-Moduls 'loc' mglich.
Die Anwendung der Routinen wird im Testmodul 'TCharClass' demonstriert.


Storage
-------
Die bekannten Funktionen zur dynamischen Anforderung und Freigabe von
Speicher. Insbesondere gibt es keinen Garbage Collector. Von diesem Modul
knnen Ausnahmen ausgelst werden.

Implementierung:
Da meist schon ein Modul namens 'Storage' vorhanden ist, das auch von der
Systembibliothek benutzt wird, ist das Modul in 'ISOStorage' umbenannt,
um Versionskonflikte zu vermeiden.
Da intern das POSIX-Modul 'mem' verwendet wird, gilt:
o Der Grenparameter von "DEALLOCATE()" wird ignoriert.
o Speicher wird bei Gelegenheit wieder ans Betriebssystem zurckgegeben.
o Die Speicherverwaltung ist ``Thread-fest'', bei Benutzung mehrerer Threads
  mssen jedoch zustzliche Funktionen aus 'mem' verwendet werden (siehe
  auch THREADS.TXT).



Die Standardbibliothek:
=======================

SysClock
--------
Dieses Modul stellt Prozeduren zum Lesen und Setzen einer Systemuhr
zur Verfgung, wobei Datum, Uhrzeit, Sommerzeit und Zeitzone bercksichtigt
werden knnen. Ob alle diese Informationen tatschlich verwendet werden,
hngt allerdings von der Implementierung bzw. dem unterliegenden
Betriebssystem ab.

Implementierung:
Die Prozeduren sind mit Hilfe des POSIX-Moduls 'tim' implementiert, so da
alle verfgbaren Informationen genutzt werden knnen. Sommerzeit und
Zeitzone knnen z.B. ber die Environmentvariable TZ gesteuert werden
(Beschreibung siehe 'tim').
Die Anwendung der Routinen wird im Testmodul 'TSysClock' demonstriert.


Strings
-------
Das Modul enthlt alle grundlegenden Operationen fr Modula-Strings, d.h.
Zeichenketten, die mit einem speziellen Endzeichen (meistens 0C)
abgeschlossen sind, wenn sie krzer sind als das umgebende Feld, sonst
durch das Feldende. Die Prozeduren arbeiten mit offenen Feldern, also
ARRAY OF CHAR, so da Strings beliebiger Lnge verwendet werden knnen.
Wenn bei einer Prozedur ein String neu erzeugt oder verndert wird und
das Ergebnis ist lnger als der zur Verfgung stehende Platz, wird das
Ergebnis entsprechend gekrzt zurckgeliefert.
Um zu testen, ob das Ergebnis vollstndig ist bzw. sein wird, gibt es fr
jede dieser Prozeduren eine zugehrige Testfunktion ("Can*All()").

Beispiel:

        IF CanAssignAll(Length(src), dst) THEN
          (* <dst> vollstaendig *)
          Assign(src, dst);
        ELSE
          (* <dst> unvollstaendig *)
          ...

Implementierung:
Da meist schon ein Modul namens 'Strings' vorhanden ist, das auch von der
Systembibliothek benutzt wird, ist das Modul in 'ISOStrings' umbenannt,
um Versionskonflikte zu vermeiden.
Die Lnge der Strings ist auf maximal 32766 Zeichen beschrnkt.
Die Anwendung der Routinen wird im Testmodul 'TStrings' demonstriert.


StringsX
--------
Dies ist ein Modul mit weiteren ntzlichen Stringfunktionen. Das Modul ist
nicht Teil des ISO-Standards, die Funktionen sind aber nach dem Muster
von 'Strings' gestaltet; es gibt z.B. ebenfalls "Can*All()"-Testfunktionen.


Da 'Strings' und 'StringsX' auch von den POSIX-Modulen verwendet werden,
mssen sie zusammen mit diesen noch vor den ISO-Modulen bersetzt werden.
Deshalb sind sie nicht im ISO-Verzeichnis, sondern im POSIX-Verzeichnis
untergebracht.


Konvertierung:
--------------

ConvTypes
---------
Dieses Modul stellt lediglich Typen fr die nachfolgenden Konvertierungs-
module zwischen interner und externer (String)Reprsentation ganzer
und reeller Zahlen zur Verfgung.

Implementierung:
Es gibt dort eine rekursive Definition eines Prozedurtyps. Da die
Definition solcher Typen (Ein ISO-Feature) nicht von allen Compilern
bewltigt wird, ist der Typ dort leicht gendert, was aber keinen Einflu
auf den Aufruf einer Prozedur dieses Typs hat.


WholeStr
--------
Konvertierung ganzer Zahlen mit und ohne Vorzeichen in Stringreprsen-
tationen und umgekehrt. Bei der Umwandlung in Strings wird die krzest-
mgliche Reprsentation gewhlt, also ohne positives Vorzeichen und
fhrende Leerzeichen. Bei der Umwandlung in die interne Darstellung
werden fhrende Leerzeichen berlesen und die Zahl ist beendet, sobald ein
Zeichen auftritt, das keine Ziffer ist. Es wird die Dezimaldarstellung
verwendet.

Implementierung:
Keine Besonderheiten.


WholeConv
---------
Stellt in erster Linie endliche Automaten zur Erkennung ganzer Zahlen
in Form einer Prozedur fr den Startzustand zur Verfgung. Diese knnen
dazu verwendet werden, eine Eingabe, z.B. bei der IO, zeichenweise solange
einzulesen wie die Zeichen Teil einer ganzen Zahl sein knnten. Auf diese
Weise werden nur soviele Zeichen aus der Eingabe entfernt wie auch wirklich
bentigt werden. Dann gibt es auch noch Tests, ob ein String eine gltige
Reprsentation einer ganzen Zahl (mit oder ohne Vorzeichen) enthlt, und
Funktionen, die die Lnge der Stringreprsentation liefern, um z.B. schon
vor der Umwandlung gengend Speicher anzufordern oder eine Ausrichtung
innerhalb einer bestimmten Feldbreite zu ermglichen. Von diesem Modul
knnen Ausnahmen ausgelst werden.

Implementierung:
Keine Besonderheiten

Die Anwendung der Module 'Whole*' wird im Testmodul 'twconv' demonstriert.


RealStr, LongStr
----------------
Konvertierung reeller Zahlen in Stringreprsentationen und umgekehrt.
Bei der Umwandlung in die interne Darstellung werden fhrende Leerzeichen
berlesen und die Zahl ist beendet, sobald ein Zeichen auftritt, das nicht
mehr Teil einer reellen Zahl sein kann (welche Zeichen (un)gltig sind,
hngt von den voranstehenden Zeichen ab). Bei der Konvertierung in
Strings kann zum einen die Anzahl der signifikanten Stellen vorgegeben
werden, zum anderen das Format der Zahl, also wissenschaftliches oder
technisches Format oder auch Fixpunktdarstellung. Des weiteren gibt
es noch die Mglichkeit, eine Zahl entweder in Fixpunktdarstellung oder
wissenschaftlicher Darstellung abhngig vom zur Verfgung stehenden Platz
im Ergebnisstring zu wandeln. Es werden weder fhrende Leerzeichen noch ein
positives Vorzeichen erzeugt.

Implementierung:
Bei Bedarf werden auch Stringreprsentationen fr Unendlich oder NaN
(Not a Number) erzeugt.


RealConv, LongConv
------------------
Stellt in erster Linie einen endlichen Automaten zur Erkennung reeller Zahlen
in Form einer Prozedur fr den Startzustand zur Verfgung. Dieser kann
dazu verwendet werden, eine Eingabe, z.B. bei der IO, zeichenweise solange
einzulesen wie die Zeichen Teil einer reellen Zahl sein knnten. Auf diese
Weise werden nur soviele Zeichen aus der Eingabe entfernt wie auch wirklich
bentigt werden. Dann gibt es auch noch Tests, ob ein String eine gltige
Reprsentation einer reellen Zahl enthlt, und Funktionen, die die Lnge der
Stringreprsentation im jeweiligen Format liefern, um z.B. schon vor der
Umwandlung gengend Speicher anzufordern oder eine Ausrichtung innerhalb
einer bestimmten Feldbreite zu ermglichen. Diese Module knnen Ausnahmen
auslsen.

Implementierung:
Keine Besonderheiten.

Die Anwendung der Module 'Long*' wird im Testmodul 'tfconv' demonstriert.


Mathematik:
-----------

RealMath, LongMath
------------------
Die Module enthalten die blichen mathematischen Routinen wie sie z.B.
auch in 'MathLib0' oder hnlichen System-Modulen vorhanden sind, als da
wren: "sqrt, "exp()", "ln()", "sin()", "cos()", "tan()", "arcsin()",
"arccos()", "arctan()". Zustzlich gibt es noch "power()" fr die
Potenzierung zu einer (fast) beliebigen Basis und "round()" zur exakten
Rundung und Konvertierung in einen ganzzahligen Wert.
Wenn die Argumente der Funktionen bestimmte Randbedingungen nicht
einhalten, z.B. nichtnegatives Argument bei "sqrt()", werden Ausnahmen
ausgelst.

Implementierung:
Die defaultmig vorhandenen Routinen bieten eine reine Software-Lsung mit
8 bzw. 16 Stellen Genauigkeit der verwendeten Approximationen (nhere
Informationen darber stehen in der Datei MATH_IMP.TXT). Beim Prprozessieren
kann festgelegt werden, ob die Routinen Ausnahmen auslsen sollen oder nicht
(Makro __NO_EXCEPTIONS__). Da ich Fehler bei den Argumenten als
Programmierfehler betrachte, werden standardmig Ausnahmen ausgelst (was
zur Programmterminierung fhrt!).
Ist eine per Line-F direkt ansprechbare FPU im Rechner (nicht 68040), wird
sie, auer bei Megamax, von allen Prozeduren auch verwendet. Evtl. Fehler in
den Argumenten oder berlufe werden dann direkt von der FPU gemeldet (falls
die Exceptions der FPU aktiviert sind) und das Benutzerprogramm mu
entsprechend darauf reagieren (siehe auch FPU.TXT).
Die Anwendung des Moduls 'RealMath' wird im Testmodul 'tmath' demonstriert.
Die Anwendung des Moduls 'LongMath' wird im Testmodul 'tlmath' demonstriert.


ComplexMath, LongComplexMath
----------------------------
Diese Module stellen im wesentlichen die gleichen Funktionen wie 'RealMath'
und 'LongMath' zur Verfgung, nur eben fr komplexe Zahlen. Zustzlich
gibt es einige Funktionen, die spezifisch fr komplexe Zahlen sind, wie
z.B. die Berechnung des Arguments oder die konjugiert komplexe Zahl.
Auch hier mssen die Argumente einiger Funktionen bestimmte Randbedingungen
einhalten, da sonst Ausnahmen ausgelst werden.

Implementierung:
Diese Module benutzen 'RealMath' und 'LongMath', so da das oben Gesagte
auch hier gilt. Da die vorhandenen Compiler keine komplexen Zahlen als
vordefinierten Datentyp bieten (ISO-Feature), sind zustzlich noch
Datentypdefinition und die fr den Typ ntigen Grundfunktionen implementiert.
Beim Prprozessieren dieser Module kann ebenfalls ber das Makro
__NO_EXCEPTIONS__ festgelegt werden, ob Ausnahmen bei falschen Argumenten
generiert werden. Die Ausnahmen sind defaultmig aktiviert. Es ist nicht
sinnvoll, bei 'RealMath' und 'ComplexMath' bzw. 'LongMath' und
'LongComplexMath' unterschiedliche Einstellungen dieses Makros zu verwenden.
Die Anwendung des Moduls 'ComplexMath' wird im Testmodul 'tcmath'
demonstriert.
Die Anwendung des Moduls 'LongComplexMath' wird im Testmodul 'tlcmath'
demonstriert.


Fr die Implementierung der oben beschriebenen mathematischen Module
werden unter anderem die Module 'RealSupport', 'LongSupport', 'RealXMath'
und 'LongXMath' verwendet. Sie gehren zwar nicht zur ISO-Bibliothek,
sind aber von allgemeinem Nutzen, ebenso wie die zustzlichen Module
'CXMath' und 'LCXMath':


RealSupport, LongSupport
------------------------
Enthalten die in ``C'' blichen Low-Level-Routinen fr reelle Zahlen:
"frexp()", "ldexp()", "fmod()", "modf()" und zustzlich eine portable
Schnittstelle zur Umwandlung zwischen ganzen und reellen Zahlen fr
Nicht-ISO-Compiler.
Ist eine per Line-F direkt ansprechbare FPU im Rechner (nicht 68040), wird
sie, auer bei Megamax, von einigen Prozeduren auch verwendet. Evtl. Fehler
in den Argumenten oder berlufe werden dann direkt von der FPU gemeldet
(falls die Exceptions der FPU aktiviert sind) und das Benutzerprogramm mu
entsprechend darauf reagieren (siehe auch FPU.TXT).
Die Anwendung des Moduls 'RealSupport' wird im Testmodul 'TRealSupport'
demonstriert.
Die Anwendung des Moduls 'LongSupport' wird im Testmodul 'TLongSupport'
demonstriert.


RealXMath, LongXMath
--------------------
Enthalten viele weitere Funktionen, wie z.B. (inverse) hyperbolische
Funktionen, Kubikwurzel, Potenz und Logarithmus zu verschiedenen Basen,
Konvertierung zwischen Polarkoordinaten und kartesischen Koordinaten.
Sie sind praktisch eine ausgelagerte Erweiterung der ISO-Mathemodule
fr reelle Zahlen, damit in den ISO-Modulen auch wirklich nur die zu
ISO gehrenden Funktionen stehen.
Benutzen die Module 'RealMath' und 'LongMath', es gibt allerdings auch
einige Approximationen. Somit stehen defaultmig ebenfalls reine
Softwarelsungen mit 8 bzw. 16 Stellen Genauigkeit zur Verfgung.
Hier kann ebenfalls ber das Makro __NO_EXCEPTIONS__ das Generieren von
Ausnahmen beeinflut werden.
Ist eine per Line-F direkt ansprechbare FPU im Rechner (nicht 68040), wird
sie, auer bei Megamax, von einigen Prozeduren auch verwendet. Evtl. Fehler
in den Argumenten oder berlufe werden dann direkt von der FPU gemeldet
(falls die Exceptions der FPU aktiviert sind) und das Benutzerprogramm mu
entsprechend darauf reagieren (siehe auch FPU.TXT).
Die Anwendung des Moduls 'RealXMath' wird im Testmodul 'txmath' demonstriert.
Die Anwendung des Moduls 'LongXMath' wird im Testmodul 'tlxmath'
demonstriert.


CXMath, LCXMath
---------------
Enthalten weitere Funktionen fr komplexe Zahlen, vor allem die (inversen)
hyperbolische Funktionen.
Sie sind praktisch eine ausgelagerte Erweiterung der ISO-Mathemodule
fr komplexe Zahlen, damit in den ISO-Modulen auch wirklich nur die zu
ISO gehrenden Funktionen stehen.
Hierbei werden Funktionen aus 'ComplexMath' bzw. 'LongComplexMath'
aufgerufen, so da die dazu gemachten Bemerkungen, auch was das Makro
__NO_EXCEPTIONS__ betrifft, hier ebenfalls gelten.


Prozesse:
---------

Processes
---------
Funktionen fr nebenlufige Programme. Es gibt die Mglichkeit, Prozesse
zu erzeugen, zu starten, zu stoppen und auf Ereignisse warten zu lassen.
Dabei kann zwischen eng oder lose gekoppelten Prozessen gewhlt werden. Bei
der ersten Art wird vom Programm explizit der nchste laufende Proze
ausgewhlt, whrend diese Wahl bei der zweiten Art einem internen
Auswahlverfahren berlassen bleibt. In jedem Fall hat das Programm die volle
Kontrolle darber, welche Prozesse lauffhig sind und welche nicht.

Implementierung:
NICHT IMPLEMENTIERT


Semaphores
----------
Bietet die Mittel, um gegenseitigen Ausschlu beim konkurrierenden Zugriff
von Prozessen auf gemeinsame Resourcen zu garantieren. Hierfr werden
allgemeine Semaphore verwendet, also Semaphore, die mitzhlen wieviele
Prozesse durch sie blockiert sind. Dieses Modul kann unabhngig von
'Processes' zur Verfgung stehen.

Implementierung:
NICHT IMPLEMENTIERT



Ein-, Ausgabe:
--------------
Den grten Teil der Standardbibliothek machen die IO-Module aus. Bei diesen
wiederum lassen sich die gerteabhngigen und die gerteunabhngigen
unterscheiden. Die gerteabhngigen bestehen im wesentlichen aus den sog.
Gertetreibern (device modules), die die Operationen bereitstellen, die von
dem entsprechenden Gert untersttzt werden. Ein Gert ist dabei nicht
unbedingt ein physikalisches Objekt, sondern reprsentiert bestimmte
logische Eigenschaften. So ist z.B. fr Dateien, bei denen der
Lese-/Schreibzeiger beliebig positioniert werden kann (random access file),
ein Gertetreiber zustndig, whrend es fr den rein sequentiellen Zugriff
(stream) einen anderen gibt.

Die Objekte, auf denen die Operationen ausgefhrt werden, heien weder
Dateien noch Strme, sondern Kanle (channels). Dieser Name wurde vermutlich
gewhlt, um die Neukonzeption der IO-Bibliothek hervorzuheben, die sich
deutlich von den verfgbaren Bibliotheken (z.B. nach Wirth) unterscheidet.

Es gibt eine Menge von Grundoperationen, die eingeschrnkt genug ist, da sie
von jedem Treiber bereitgestellt werden kann. Ausschlielich auf diesen
Grundoperationen bauen dann die universellen IO-Module auf, die nicht mehr
von einem bestimmten Gertetreiber abhngig sind. Spezielle Eigenschaften
des jeweiligen Gerts werden durch zustzliche Operationen von den
Treibermodulen direkt zur Verfgung gestellt. Dazu gehren i.allg. die
Operationen zum ffnen und Schlieen von Kanlen. Auf diese Weise lt sich
eine gute Trennung zwischen hardwareabhngigen und -unabhngigen Dingen
erreichen.

Die universellen Operationen, die sich im wesentlichen auf das Lesen und
Schreiben von Feldern beschrnken, sind in zwei Gruppen geteilt:
Textoperationen mit dem Typ CHAR und Binroperationen mit dem Typ
LOC. Bei den Binroperationen wird einfach nur eine bestimmte Anzahl von LOCs
gelesen oder geschrieben, ohne da deren Inhalt interpretiert wird. Bei den
Textoperationen werden jedoch Zeilenenden beachtet: Keine Leseoperation
liest ber ein Zeilenende hinweg! Ein Zeilenende mu erst explizit aus der
Eingabe entfernt werden. Wichtig ist, da nirgendwo festgelegt ist,
wie ein Zeilenende aussieht; wenn ein Zeilenende auftaucht, kann dies
lediglich ber das Resultat einer Textleseoperation festgestellt werden,
das Zeilenende selber wird niemals gelesen oder taucht sonst irgendwo
als Zeichen auf. Um ein Zeilenende beim Schreiben zu erzeugen, gibt es
eine spezielle Prozedur. Damit ist Unabhngigkeit von der Reprsentation
des Zeilenendes erreicht: es ist fr den Programmierer vllig egal aus
welchen und wievielen Zeichen ein Zeilenende besteht!

Mit dem oben erwhnten Resultat einer Leseoperationen kommen wir dann zum
Knackpunkt der IO-Bibliothek (zumindest fr Nicht-ISO-Compiler): Lediglich
bei Leseoperationen wird ein Status gesetzt, der abgefragt werden kann;
dies jedoch auch nur, um zu erfragen, ob ein Zeilenende oder das Ende der
Eingabe aufgetreten ist, oder ob bei einer Blockleseoperation weniger Objekte
als verlangt gelesen wurden. Fehler (nicht nur) bei der unterliegenden IO,
und dazu zhlt auch alles, was bei einer Schreiboperation eine Abweichung vom
Gewnschten hervorrufen kann, werden nicht ber Variablen, Flags oder
Prozeduren mitgeteilt, sondern ber Ausnahmen! D.h. wenn kein Handler
fr die jeweilige Ausnahme installiert ist, wird das Programm terminiert,
was besonders bei vollen Datentrgern rgerlich ist, wenn weniger Bytes
geschrieben werden konnten als verlangt! Durch diese etwas andere Art
der Fehlerbehandlung wird zwar eine gute Trennung vom normalen
Programmflu erreicht, aber es mssen eben Ausnahmen und Ausnahmehandler
vom Compiler untersttzt werden.

Die gerteunabhngigen Module sind jeweils in zwei Versionen vorhanden:
Module, die mit einem S (z.B. STextIO im Gegensatz zu TextIO) beginnen,
bieten die gleichen Operationen wie die Module ohne S, benutzen aber
Defaultkanle, so da bei den Operationen kein Kanal angegeben bzw.
berhaupt nicht mit Kanlen gearbeitet werden mu, wenn die automatisch
vorhandenen Standardkanle verwendet werden. Das S steht brigens nicht
fr Standard-IO, sondern fr Simple-IO.

Allgemein gilt: Jedes dieser Module kann eine Ausnahme auslsen, wenn die
angegebene Kanalkennung fehlerhaft ist.

Implementierung:
Allen Treibermodulen gemeinsam sind die folgenden Eigenschaften:
Die Implementierung sttzt sich voll auf die POSIX-Module 'file' und 'term'.
Zeilenende: Ist die unterliegende Datei ein (Pseudo)Terminal, gelten sowohl
CR als auch LF als Zeilenende, die Kombination CR+LF besteht also aus zwei
Zeilenenden. Ist die Datei kein Terminal, gelten sowohl alleinstehende
LFs als auch die Kombination CR+LF als Zeilenende; alleinstehende CRs haben
keine Spezialbedeutung und werden als normale Zeichen bertragen.
Beim Schreiben eines Zeilenendes wird die Environmentvariable UNIXMODE
beachtet: Wenn beim ffnen des Kanals im String das Flag 'b' gesetzt war
(Binrmodus, Unixmodus), wird ein Zeilenende als ein einzelnes LF erzeugt,
wenn das Flag nicht gesetzt war (Textmodus, Dosmodus) oder die
Environmentvariable nicht existiert, werden LFs, denen kein CR vorangeht,
in CR+LF umgewandelt.
Wenn der Kanal sowohl zum Lesen als auch zum Schreiben geffnet wurde,
kann beliebig zwischen Lese- und Schreiboperationen ohne ein zwischen-
geschaltetes 'Flush' gewechselt werden. Ebenso ist ein Wechsel zwischen
Text- und Binrmodus mglich.
Ein- und Ausgabe sind voll gepuffert. Bei Terminals ist die Ausgabe
zeilenweise gepuffert, d.h. der Puffer wird nach jedem Zeilenende
rausgeschrieben.
Es wird angenommen, da die Typen CHAR und LOC (oder ANYTYPE) jeweils ein
Byte belegen!

Die von den Gertetreibern erzeugten Ausnahmen lassen sich in zwei Klassen
einteilen:
1) Ausnahmen, die durch logische Fehler ausgelst werden; z.B. der Versuch
   eine Schreiboperation auszufhren, obwohl der Kanal gar nicht zum
   Schreiben geffnet ist, oder die Angabe einer fehlerhaften Kanalkennung.
2) Ausnahmen, die durch Ergebnisse der verwendeten Betriebssystemroutinen
   ausgelst werden; z.B. weil eine Schreiboperation wegen vollem Datentrger
   nicht erfolgreich war.

Fehler, die zu Ausnahmen der ersten Klasse fhren, betrachte ich als
Programmierfehler; deswegen sind sie nicht abschaltbar. Bei der zweiten
Klasse von Fehlern kann jedoch beim Prprozessieren eines Gertetreibers
mit dem Makro __NO_IO_EXCEPTIONS__ festgelegt werden, ob Ausnahmen erzeugt
werden. Defaultmig werden keine Ausnahmen erzeugt, da IO-Fehler
durchaus auftreten knnen und dann darauf reagiert werden mu. Ohne
Vorhandensein von Ausnahme-Handlern wrde das Programm einfach terminiert,
was i.allg. nicht die angemessene Reaktion ist. Um trotzdem feststellen
zu knnen, ob eine Operation erfolgreich verlaufen ist, habe ich die
Semantik einer ISO-Operation kurzerhand erweitert: Die Funktion
"IOChan.DeviceError()" sollte eine vom Gertetreiber gespeicherte Fehlernummer
liefern, die aber nur gltig ist, wenn eine Ausnahme aufgetreten ist, so da
im Ausnahme-Handler selektiv auf unterschiedliche Fehler reagiert werden
kann. In der jetzigen Form wird die Fehlernummer vor jeder IO-Operation
auf Null gesetzt und vom Gertetreiber verndert, sobald ein Fehler
aufgetreten ist. Der Fehlercode entspricht den Werten aus dem POSIX-Modul 'e'.
Somit ergibt sich folgende Vorgehensweise (die aber nicht ISO-gem ist!):

<Irgendeine IO-Operation>
IF DeviceError(<channel>) # 0 THEN
  <Fehlerbehandlung>
ELSE
  ...



Die Module im einzelnen:

ChanConsts
----------
Definiert Aufzhlungstypen, die beim ffnen von Kanlen verwendet werden.

Implementierung:
Keine Besonderheiten.


IOLink
------
Bietet Prozeduren und Typen fr die Implementierung von Gertetreibern.
Neue Kanle werden mit Defaultoperationen versehen, die bei Aufruf eine
Ausnahme auslsen. Wenn eine Operation vom Gertetreiber untersttzt wird,
ersetzt sie diese Defaultoperation.

Implementierung:
Die Anzahl der offenen Kanle ist intern begrenzt. Es wird eine
Modulterminierung installiert, die bei Programmende alle noch offenen Kanle
schliet und dabei auch gepufferte Daten zurckschreibt.


StdChans
--------
Es gibt keine Operationen zum ffnen und Schlieen von Kanlen, stattdessen
gibt es Funktionen, die die Kennungen bereits vorhandener Kanle liefern.
Das sind zum einen die bereits geffneten Standardkanle, die zu system-
spezifischen Ein- und Ausgabedateien fhren; diese Kanle bleiben whrend
des gesamten Programmlaufs konstant. Dann gibt es einen Null-Kanal, der beim
Lesen immer ein Ende der Eingabe meldet und alle Ausgaben ``schluckt''.
Und schlielich gibt es die Defaultkanle, die bei den S-Modulen benutzt
werden, bei denen kein Kanal angegeben werden mu. Die Defaultkanle sind
bei Programmstart auf die Standardkanle gesetzt, knnen aber jederzeit
auf andere Kanle umgelenkt werden (z.B. Kanle eines Treibers fr ein
Fenstersystem -- was nur noch jemand implementieren mte...).

Implementierung:
Das Modul enthlt nicht direkt die Implementierung der Operationen, sondern
ruft lediglich die Prozeduren auf, die ber Zeigervariablen auf Tabellen mit
den Gerteoperationen in einem tieferliegenden Modul ('StdChanBase')
erreichbar sind (was fr'n Satz...). Durch Ersetzen der Prozeduren in diesen
Tabellen lt sich das Verhalten der Standardkanle ndern. Als Beispiel gibt
es das Modul 'StdInOut', das die Operationen der Standardkanle, soweit es
geht, ber die bekannten Prozeduren aus 'InOut' implementiert. Um diese
Operationen zu aktivieren, reicht ein Import des Moduls aus. 'StdInOut' ist
fr Systeme mit Load-Time-Linking whrend der Programmentwicklung vielleicht
ganz sinnvoll, da 'InOut' dort normalerweise ber ein GEM-Fenster abgewickelt
wird. 'StdInOut' ist aber nur ein schneller Hack, der die ntigsten Sachen
zur Verfgung stellt; fr fertige Programme ist das Modul absolut ungeeignet!
Ein Treiber fr GEM-Fenster existiert leider bisher nicht. Vielleicht
mchte jemand sowas programmieren? Von mir selbst wird es das wohl nicht
geben. Ich stelle mir vor, da es ein oder mehrere allgemeine Basismodule
gibt, die smtliche Fenster- und Ereignisbelange abdecken, und darauf
aufgesetzt ein Treibermodul im Stile der anderen Gertetreiber.

Defaultmig gilt fr die Implementierung der Standardkanle:
Die Standardkanle fhren zu den POSIX-Dateien STDIN_FILENO, STDOUT_FILENO
und STDERR_FILENO. Alle Kanle untersttzen Text- und Binroperationen.
Von der Standardeingabe kann nur gelesen werden; die Eingabe ist gepuffert.
Auf die Standardausgabe kann nur geschrieben werden; handelt es sich um
ein Terminal, wird die Ausgabe zeilenweise gepuffert, bei normalen
Dateien ist die Ausgabe voll gepuffert. Der Standardfehlerkanal ist sowohl
zum Lesen als auch zum Schreiben geeignet; dieser Kanal ist nicht gepuffert.
Fr die Standardausgabe wird eine Modulterminierung installiert, die beim
Programmende noch den Puffer rausschreibt.


ProgramArgs
-----------
Dies ist ein Pseudogert, um das Lesen von Programmargumenten mit den
vorhandenen IO-Operationen durchfhren zu knnen. Es gibt keine Operationen
zum ffnen und Schlieen eines Kanals, stattdessen kann die Kennung eines
bereits offenen Kanals erfragt werden, von dem die Programmargumente gelesen
werden knnen. Weiterhin gibt es die Mglichkeit, abzufragen, ob noch ein
weiteres Argument vorhanden ist, und zum nchsten Argument berzugehen.
Die Leseoperationen beziehen sich immer auf das aktuelle Argument; wenn
das Argument beendet ist, wird ein Dateiende angezeigt, und es mu explizit
zum nchsten Argument gewechselt werden.
Dieses Modul kann Ausnahmen auslsen.

Implementierung:
Es wird das POSIX-Modul 'args' benutzt, so da Programmargumente sowohl
aus der Basepage-Kommandozeile als auch ber das ARGV-Verfahren inkl.
Erweiterung fr leere Argumente ermittelt werden knnen.
Da die mglichen Fehler ausschlielich logischer Natur sind (d.h. Programmier-
fehler), werden auch Ausnahmen generiert.
Das Programm 'PrintArgs' demonstriert dieses Modul, indem es alle
Programmargumente mit den Standard-IO-Operationen ausgibt.


StreamFile
----------
Gertetreiber fr unabhngige sequentielle Datenstrme. Das ist die
universellste Schnittstelle zum Dateisystem, da keine speziellen Eigenschaften
vorausgesetzt werden, dafr knnen Dateien aber nur rein sequentiell gelesen
oder beschrieben werden. Ein Kanal kann allerdings gleichzeitig zum Lesen und
Schreiben geffnet werden, wobei beide Operationen unabhngig voneinander
laufen, d.h. Lese- und Schreibposition sind nicht dasselbe.

Implementierung:
Es knnen alle Dateiarten verwendet werden, allerdings darf auf einem TOS-
Dateisystem keine Datei gleichzeitig zum Lesen und Schreiben geffnet sein.
Ein- und Ausgabe sind voll gepuffert. Handelt es sich um ein Terminal, wird
die Ausgabe zeilenweise gepuffert.


SeqFile
-------
Gertetreiber fr rckspulbare, sequentielle Dateien. Neben den Operationen
zum ffnen und Schlieen von Kanlen, gibt es Operationen, die es erlauben,
eine zum Lesen geffnete Datei zu beschreiben (wobei die Datei vorher auf
die Lnge Null gekrzt wird), oder eine zum Schreiben geffnete Datei zu
lesen (dabei wird der vorher geschriebene Inhalt erneut gelesen). Das
Lesen und Schreiben erfolgt streng sequentiell, und beim Schreiben entspricht
die Dateilnge immer der augenblicklichen Schreibposition; beim ffnen
kann allerdings die anfngliche Schreibposition an das Ende der bisherigen
Datei gesetzt werden, anstatt die Datei auf Lnge Null zu krzen.

Implementierung:
Es knnen nur regulre Dateien (keine Terminals) verwendet werden, da nur
diese das ``Rckspulen'' (lseek) erlauben. Ein- und Ausgabe sind voll
gepuffert.


RndFile
-------
Gertetreiber fr Dateien mit wahlfreiem Zugriff. Auer den Operationen zum
ffnen und Schlieen von Kanlen gibt es noch die fr diese Art von Kanlen
spezifischen Operationen zum Abfragen und Verndern der Lese/Schreibposition.
Die Kanle knnen gleichzeitig zum Lesen und Schreiben geffnet sein, es gibt
allerdings nur eine gemeinsame Lese/Schreibposition.

Implementierung:
Es knnen nur regulre Dateien (keine Terminals) verwendet werden, da nur
diese das Setzen des Lese/Schreibzeigers (lseek) erlauben. Ein- und Ausgabe
sind voll gepuffert.


TermFile
--------
Gertetreiber fr das Terminal. Alle Kanle sind mit demselben Terminal
verbunden, das lediglich intern festgelegt wird. Ein Kanal kann in zwei
Modi geffnet werden: Zeilen- und Einzelzeichenmodus. Der wesentliche
Unterschied liegt dabei im Zeitpunkt des evtl. auftretenden Echos.

Implementierung:
NICHT IMPLEMENTIERT


IOConsts
--------
Definiert lediglich einen Aufzhlungstyp fr die mglichen Ergebnisse
einer Leseoperation.

Implementierung:
Keine Besonderheiten.


IOChan
------
Schnittstelle fr die gerteunabhngigen IO-Module. Mit Hilfe dieser
Prozeduren werden die IO-Module unabhngig von den speziellen Gerte-
eigenschaften implementiert. Hauptpunkt sind die Operationen zum blockweisen
Lesen und Schreiben im Binr- und Textmodus; dann gibt es eine Operation
zum Schreiben eines Zeilenendes im Textmodus und ein paar weitere
Hilfsoperationen. Fr das zeichenweise Einlesen im Textmodus gibt es noch
eine Besonderheit: Bei den blichen IO-Bibliotheken wird ein Zeichen gelesen
und ist damit aus der Eingabe entfernt, damit das nchste Zeichen mit
derselben Prozedur gelesen werden kann. Hier wird jedoch ein Zeichen gelesen,
ohne es zu entfernen, so da beim nchsten Mal dasselbe Zeichen gelesen wird.
Fr das Entfernen des Zeichens aus der Eingabe gibt es eine extra Operation.
Der Sinn liegt darin, da man sich erst einmal das nchste Zeichen anguckt,
und nur wenn es den Anforderungen entspricht, z.B. noch zu einer Zahl gehrt,
wird es entfernt. Auf diese Weise erspart man sich eine sonst ntige
'Unread'-Operation.
Schlielich gibt es noch eine Funktion, die die Kennung eines ungltigen
Kanals liefert. Diese Kennung ist whrend des gesamten Programmlaufs konstant
und wird bei verschiedenen Prozeduren der IO-Bibliothek dafr benutzt, einen
Kanal explizit als ungltig zu kennzeichnen.

Implementierung:
Der mit "DeviceError()" ermittelbare Fehlercode des Kanals wird vor jeder
Operation auf Null gesetzt, so da ein Fehler nach Ende der Operation durch
"DeviceError()" # 0 festgestellt werden kann.


IOResult, SIOResult
-------------------
Es gibt lediglich eine einzige Funktion, mit der das Ergebnis der letzten
Leseoperation erfragt werden kann.

Implementierung:
Keine Besonderheiten.


RawIO, SRawIO
-------------
Es gibt zwei Funktionen, mit denen ein ARRAY OF LOC gelesen oder
geschrieben werden kann. Der Inhalt wird nicht interpretiert, da die Binr-
operationen verwendet werden.

Implementierung:
Keine Besonderheiten.


TextIO, STextIO
---------------
Ein- und Ausgabe von Text. Ausgabeoperationen gibt es fr Einzelzeichen,
Strings und Zeilenenden. Bei der Eingabe knnen Einzelzeichen gelesen,
alle Zeichen bis zum nchsten Zeilenende entfernt oder Strings auf mehrere
Arten gelesen werden.

Implementierung:
Keine Besonderheiten.


WholeIO, SWholeIO
-----------------
Es gibt jeweils zwei Funktionen zum Lesen und Schreiben von ganzen Zahlen
in die oder von der externe(n) Darstellung (Stringreprsentation) mit und
ohne Vorzeichen.

Beim Lesen werden fhrende Leerzeichen berlesen und die Eingabe ist beendet,
sobald ein Zeichen auftritt, das nicht mehr Teil einer ganzen Zahl sein kann.
Das erste nicht verwendete Zeichen wird nicht aus der Eingabe entfernt,
so da es fr eine nachfolgende Leseoperation zur Verfgung steht.

Beim Schreiben kann eine Feldbreite angegeben werden, in der die Zahl
rechtsbndig steht. Ist die Feldbreite grer als die Stringreprsentation,
wird von links mit Leerzeichen auf die Feldbreite aufgefllt, ist die
Feldbreite kleiner, wird sie der Lnge der Reprsentation angepat.
Es wird kein positives Vorzeichen geschrieben.

Implementierung:
Bei der Eingabe drfen die Zahlenreprsentationen eine bestimmte Lnge
nicht berschreiten, sonst wird ein falsches Format diagnostiziert;
trotzdem werden alle zur Zahl gehrenden Zeichen eingelesen.


RealIO, SRealIO, LongIO, SLongIO
--------------------------------
Es gibt eine Prozedur zum Einlesen reeller Zahlen aus der externen
Stringreprsentation in die interne Darstellung und vier Operationen
zum Schreiben reeller Zahlen von der internen in die externe Darstellung.

Beim Lesen werden fhrende Leerzeichen berlesen und die Zahl ist beendet,
sobald ein Zeichen auftritt, das nicht mehr Teil einer reellen Zahl sein
kann (welche Zeichen (un)gltig sind, hngt von den vorangegangenen Zeichen
ab).

Beim Schreiben kann eine Feldbreite angegeben werden, in der die Zahl
rechtsbndig steht. Ist die Feldbreite grer als die Stringreprsentation,
wird von links mit Leerzeichen auf die Feldbreite aufgefllt, ist die
Feldbreite kleiner, wird sie der Lnge der Reprsentation angepat.
Es kann ebenfalls die Anzahl der signifikanten Stellen vorgegeben
werden, und das Format der Stringreprsentation, also wissenschaftliches
oder technisches Format oder auch Fixpunktdarstellung.
Des weiteren gibt es noch die Mglichkeit, eine Zahl entweder in
Fixpunktdarstellung oder wissenschaftlicher Darstellung abhngig von der
Feldbreite zu schreiben. Es wird kein positives Vorzeichen geschrieben.

Implementierung:
Bei der Eingabe drfen die Zahlenreprsentationen eine bestimmte Lnge
nicht berschreiten, sonst wird ein falsches Format diagnostiziert;
trotzdem werden alle zur Zahl gehrenden Zeichen eingelesen.



Literatur:
==========

o BSI, Leicester University, D.J. Andrews et al.,
  Information technology -- Programming languages -- Modula-2,
  2nd Committee Draft Standard: CD 10514, December 1992,
  Document SC22/WG13 D181.

o BSI, Leicester University, D.J. Andrews et al.,
  Information technology -- Modula-2,
  Draft International Standard: DIS 10514, June 1994,
  Document ISO/IEC JTC1/SC22/WG13 D203.

o Einige Ausgaben des "Journal of Pascal, Ada & Modula-2" von 1989 und 1990.
